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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This document specifies a leasequery exchange for the Dynamic Host 
Configuration Protocol for IPv6 (DHCPv6) that can be used to obtain 
lease information about DHCPv6 clients from a DHCPv6 server. This 
document specifies the scope of data that can be retrieved as well as 
both DHCPv6 leasequery requestor and server behavior. This document 
extends DHCPv6. 
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Les 


Introduction 


The DHCPv6 [2] protocol specifies a mechanism for the assignment of 
both IPv6 address and configuration information to IPv6 nodes.  IPv6 
Prefix Options for DHCPv6 [4] specifies a mechanism for the automated 
delegation of IPv6 prefixes and related options. Similar to DHCPv4 
[5], DHCPv6 servers maintain authoritative information related to 
their operations including, but not limited to, lease information for 
IPv6 addresses and delegated prefixes. 


The requirement exists in various types of IPv6 deployments, 
particularly those of a broadband variety, to leverage DHCPv6 [2] for 
retrieving data related to the operation of DHCPv6 servers 
programmatically. In particular, it is desirable to be able to 
extract lease information about IPv6 addresses and delegated prefixes 
assigned using DHCPv6 [2] [4]. Specific examples where this 
information has illustrated value are in broadband networks to 
facilitate access control by edge devices. This capability to 
programmatically extract lease data from the DHCPv6 server is called 
leasequery. 


The leasequery capability described in this document parallels the 
DHCPv4 leasequery capability documented in [3]. As such, it shares 
the basic motivations, background, design goals and constraints as 
described in [3]. Differences are due to the differences between 
IPv4 and IPv6 and by extension, DHCPv4 and DHCPv6. For example, 
Neighbor Discovery [7] is used in IPv6 instead of the Address 
Resolution Protocol (ARP) [8] (Section 4.1 of [3]) and DOCSIS 3.0 
[11] defines IPv6 support for cable modem environments. 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [1]. 


DHCPv6 terminology is defined in [2]. Terminology specific to DHCPv6 
leasequery Can be found below: 


access concentrator 
An access concentrator is a router or switch at the 
broadband access provider’s edge of a public 
broadband access network. This document assumes that 
the access concentrator includes the DHCPv6 relay 
agent functionality. 
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client (s) The nodes that have one or more bindings with a 
DHCPv6 server. This does not refer to the node 
issuing the LEASEQUERY unless it itself has one or 
more bindings with a DHCPv6 server. 


gleaning Gleaning is the extraction of location information 
from DHCPv6 messages, as the messages are forwarded 
by the DHCP relay agent function. 


location information 
Location information is information needed by the 
access concentrator to forward traffic to a 
broadband-accessible host. This information includes 
knowledge of the host hardware address, the port or 
virtual circuit that leads to the host, and/or the 
hardware address of the intervening subscriber modem. 


requestor The node that sends LEASEQUERY messages to one or 
more servers to retrieve information on the bindings 
for a client. 


3. Protocol Overview 


The focus of this document is to extend the DHCPv6 protocol to allow 
processes and devices that wish to access information from a DHCPv6 
server to do so in a lightweight and convenient manner. It is 
especially appropriate for processes and devices that already 
interpret DHCPv6 messages. 


The LEASEQUERY message is a query message only and does not affect 
the state of the IPv6 address or prefix, or the binding information 
associated with it. 


One important motivating example is that the LEASEQUERY message 
allows access concentrators to query DHCP servers to obtain location 
information of broadband access network devices. This is described 
in Section 1 of [3] for IPv4. 


3.1. On-Demand Query 


The on-demand leasequery capability allows requesting just the 
information necessary to satisfy an immediate need. If the requestor 
is an access concentrator, then the immediate need will typically be 
that it has received an IPv6 packet and it needs to refresh its 
information concerning the DHCPv6 client to which that IPv6 address 
is currently leased. In this case, the request will be by address. 
This fits clearly into the single request/response cycle common to 
other DHCPv6 message exchanges. 
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However, this approach has limitations when used with prefix 
delegation [4] as no traffic may arrive because the access 
concentrator is unable to inject the appropriate routing information 
into the routing infrastructure, such as after a reboot. This 
approach does work if the access concentrator is configured to inject 
routing information for a prefix that aggregates potentially 
delegated prefixes. Or, it also works if the access concentrator and 
requesting router use a routing protocol; as then the requesting 
router can trigger the access concentrator to request information 
from a DHCPv6 server and inject appropriate routing information into 
the routing infrastructure. 


3.2. Anticipatory Query 


A second approach for requesting information from a DHCPv6 server 
would be to use a leasequery-like capability to rebuild an internal 
data store containing information available from a DHCPv6 server. 
The rebuilding of the data store in this approach can take place as 
soon as possible after the need to rebuild it is discovered (such as 
on booting), and doesn't wait on the receipt of specific packets to 
trigger a piecemeal database update (as is the case for on-demand 
leasequery). This approach would also remove the limitation 
discussed above for prefix delegation. 


This anticipatory query is not specified in this document and is an 
area of future work. 


3.3. Query Types 
Leasequery provides for the following queries: 


Query by IPv6 address - This query allows a requestor to request 
from a server the bindings for a client that either is bound to 
the address or has been delegated the prefix that contains the 
address. 


Query by Client Identifier (DUID) - This query allows a requestor to 
request from a server the bindings for a specific client on a 
specific link or a list of the links on which the client has one 
or more bindings. 
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4. Protocol Details 
4.1. Message and Option Definitions 
4.1.1. Messages 


The LEASEQUERY and LEASEQUERY-REPLY messages use the Client/Server 
message formats described in [2], Section 6. Two new message codes 
are defined: 


LEASEQUERY (14) - A requestor sends a LEASEQUERY message to any 
available server to obtain information on a client’s leases. The 
options in an OPTION_LO QUERY determine the query. 


LEASEQUERY-REPLY (15) - A server sends a LEASEQUERY-REPLY message 
containing client data in response to a LEASEQUERY message. 


4.1.2. Options 
4.1.2.1. Query Option 


The Query option is used only in a LEASEQUERY message and identifies 
the query being performed. The option includes the query type, link- 
address (or 0::0), and option(s) to provide data needed for the 
query. 


The format of the Query option is shown below: 
0 1 2 3 


0 1.223 4 5 6 "1:08: 9-01: 2:34:56 718.90 1.234 5.6.7 8 9.0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 


| OPTION_LQ_QUERY | option-len | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| query-type | 


+-+-+-+-+-+-+-+-+ 
| link-address 
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
A. 

query-options 
A ee ee ced 


opt ion-code OPTION LQ QUERY (44) 


option-len 17 + length of query-options field. 
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link-address A global address that will be used by the 
server to identify the link to which the 
query applies, or 0::0 if unspecified. 


query-type The query requested (see below). 
query-options The options related to the query. 
The query-type and required query-options are: 


QUERY_BY_ADDRESS (1) - The query-options MUST contain an 
OPTION_IAADDR option [2]. The link-address field, if not 0::0, 
specifies an address for the link on which the client is located 
if the address in the OPTION_IAADDR option is of insufficient 
scope. Only the information for the client that has a lease for 
the specified address or was delegated a prefix that contains the 
specified address is returned (if available). 


QUERY BY CLIENTID (2) - The query-options MUST contain an 
OPTION CLIENTID option [2]. The link-address field, if not 0::0, 
specifies an address for the link on which the client is located. 
If the link-address field is 0::0, the server SHOULD search all of 
its links for the client. 


The query-options MAY also include an OPTION ORO option [2] to 
indicate the options for each client that the requestor would like 
the server to return. Note that this OPTION ORO is distinct and 
Separate from an OPTION ORO that may be in the requestor's LEASEQUERY 
message. 


If a server receives an OPTION LQ QUERY with a query-type it does not 
support, the server SHOULD return an UnknownQueryType status-code. 

If a server receives a supported query-type but the query-options is 

missing a required option, the server SHOULD return a MalformedQuery 

status-code. 
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4.1.2.2. Client Data Option 


The Client Data option is used to encapsulate the data for a single 
client on a single link in a LEASEQUERY-REPLY message. 


The format of the Client Data option is shown below: 


0 1 2 3 
0.2.3 4-5-6- 4.8.90: 1.2.3 4 5.6. 72;,8 9.0 1.2 3 4 5 6 7.8 90; 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| OPTION_CLIENT_DATA | option-len | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


client-options 
+—-+-+-+-4+-4+-4+-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4+-4-4+-4+-4-4-4-4 
opt ion-code OPTION_CLIENT_DATA (45) 


option-len Length, in octets, of the encapsulated client- 
options field. 


client-options The options associated with this client. 


The encapsulated client-options include the OPTION CLIENTID, 

OPTION IAADDR, OPTION IAPREFIX, and OPTION CLT TIME options and other 
options specific to the client and requested by the requestor in the 
OPTION ORO in the OPTION LQ QUERY's query-options. The server MUST 
return all of the client's statefully assigned addresses and 
delegated prefixes, with a non-zero valid lifetime, on the link. 
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4.1.2.3. Client Last Transaction Time Option 


The Client Last Transaction Time option is encapsulated in an 
OPTION_CLIENT_DATA and identifies how long ago the server last 
communicated with the client, in seconds. 


The format of the Client Last Transaction Time option is shown below: 


0 1 2 3 
OA 4. TAS AOL 1279 AEB Ge «B. 9:0. 1:52.34. 09 67 a el. 
dh + RR dd de de e e de de dd dd de 4 4 4 4 + + + ++ + + +++ 
| OPTION_CLT_TIME | option-len | 
dh + + RO dd e e e de e dd dd de de 4 4 4 4 + + + +++ ++ +++ 

| client-last-transaction-time 
$ hh RR RO dd de dd de dd dd de de 4 4 4 4 + + + + + +++ +++ 


option-code OPTION CLT TIME (46) 
option-len 4 
client-last-transaction-time 
The number of seconds since the server last 
communicated with the client (on that link). 
The client-last-transaction-time is a positive value and reflects the 


number of seconds since the server last communicated with the client 
(on that link). 
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4.1.2.4. Relay Data 


The Relay Data option is used only in a LEASEQUERY-REPLY message and 
provides the relay agent information used when the client last 
communicated with the server. 


The format of the Relay Data option is shown below: 


0 1 2 3 
OF A! 23 00 6 71:8 90 L:2-3^4 5-6^7c-8. 9-0. 1:23 4,96. 7:8 9-0 d 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| OPTION_LO_RELAY_DATA | option-len | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| | 
| 


| peer-address (IPv6 address) 


(——————R——R——————————A—A^AAA^AW^AA^—^—4—^—4^A^AA^A—^^A^A^A^—^A—^A^A^R^A^A—A^A^——€^—5^RARA————— 
| DHCP-relay-message | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


option-code OPTION_LQ_RELAY_DATA (47) 

option-len 16 + length of DHCP-relay-message. 

peer-address The address of the relay agent from which 
the relayed message was received by the 
server. 


DHCP-relay-message 
The last complete relayed message, excluding 
the client's message OPTION_RELAY_MSG, 
received by the server. 


This option is used by the server to return full relay agent 
information for a client. It MUST NOT be returned if the server does 
not have such information, either because the client communicated 
directly (without relay agent) with the server or if the server did 
not retain such information. 


If returned, the DHCP-relay-message MUST contain a valid (perhaps 

multi-hop) RELAY-FORW message as the most recently received by the 
server for the client. However, the (innermost) OPTION_RELAY_MSG 

option containing the client's message MUST have been removed. 
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This option SHOULD only be returned if requested by the OPTION_ORO of 
the OPTION LQ QUERY. 


4.1.2.5. Client Link Option 


The Client Link option is used only in a LEASEQUERY-REPLY message and 
identifies the links on which the client has one or more bindings. 

It is used in reply to a query when no link-address was specified and 
the client is found to be on more than one link. 


The format of the Client Link option is shown below: 


0 1 2 3 
O0. d 2:53:74. 5..6. 18:90 1:2 3:4 7576 78-901: 324 56:7 ;:8 9:0. 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ O O A X — o o o ho + + 
| OPTION_LQ_CLIENT_LINK | option-len | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BM BBC. o o o ho ++ 
| link-address (IPv6 address) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
| link-address (IPv6 address) 
E +++ 
+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 
option-code OPTION_LQ_CLIENT_LINK (48) 


option-len Length of the list of links in octets; 
must be a multiple of 16. 


link-address A global address used by the server to 
identify the link on which the client is 
located. 


A server may respond to a query by client-id, where the 0::0 link- 
address was specified, with this option if the client is found to be 
on multiple links. The requestor may then repeat the query once for 
each link-address returned in the list, specifying the returned link- 
address. If the client is on a single link, the server SHOULD return 
the client's data in an OPTION_CLIENT_DATA option. 
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4.1.3. Status Codes 


The following new status codes are defined: 


UnknownQueryType (7) - The query-type is unknown to or not supported 
by the server. 


MalformedQuery (8) - The query is not valid; for example, a required 
query-option is missing from the OPTION_LO QUERY. 


NotConfigured (9) - The server does not have the target address or 
link in its configuration. 


NotAllowed (10) - The server does not allow the requestor to issue 
this LEASEQUERY. 


4.1.4. Transmission and Retransmission Parameters 


This section presents a table of values used to describe the message 
transmission behavior for leasequery. 


Parameter Default Description 

LO _ TIMEOUT 1 sec Initial LEASEQUERY timeout 

LO MAX RT 10 secs Max LEASEQUERY timeout value 
LO MAX RC 5 Max LEASEQUERY retry attempts 


4.2. Message Validation 
E 2l. LEASEQUERY 
Requestors and clients MUST discard any received LEASEQUERY messages. 


Servers MUST discard any received LEASEQUERY messages that meet any 
of the following conditions: 


o the message does not include an OPTION CLIENTID option. 


o the message includes an OPTION SERVERID option but the contents of 
the OPTION SERVERID option does not match the server's identifier. 


o the message does not include an OPTION LQ QUERY option. 
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4.2.2. | LEASEQUERY-REPLY 


Requestors MUST discard any received LEASEQUERY-REPLY messages that 
meet any of the following conditions: 


o the message does not include an OPTION SERVERID option. 


o the message does not include an OPTION CLIENTID option, or the 
contents of the OPTION CLIENTID option do not match the DUID of 
the requestor. 


o the "transaction-id" field in the message does not match the value 
used in the original message. 


Servers and Relay Agents (on the server port, 547 [2]) MUST discard 
any received LEASEQUERY-REPLY messages. 


4.3.  DHCPv6 Leasequery Requestor Behavior 


This section describes how a requestor initiates lease data retrieval 
from DHCPv6 servers. 


4.3.1. Creation of LEASEQUERY 


The requestor sets the "msg-type" field to LEASEQUERY. The requestor 
generates a transaction ID and inserts this value in the 
"transaction-id" field. 


The requestor MUST include an OPTION CLIENTID option to identify 
itself to the server. 


The requestor MUST include an OPTION LQ QUERY option and set the 
query-type, link-address, and query-options as appropriate to the 
query-type (Section 4.1.2.1). 


The requestor SHOULD include an OPTION SERVERID if it is not 
unicasting the LEASEQUERY yet only wants a response from a specific 
server. 


4.3.2. Transmission of LEASEQUERY 


The requestor MAY be configured to use a list of destination 
addresses, which MAY include unicast addresses, the All DHCP Servers 
multicast address, or other addresses selected by the network 
administrator. If the requestor has not been explicitly configured, 
it MAY use the A11 DHCP Servers multicast address as the default. 
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4. 


3. 


The requestor SHOULD send LEASEQUERY to one or more DHCPv6 servers 
that are known to possess authoritative information concerning the 
query target. 


In the absence of information concerning which DHCPv6 servers might 
possess authoritative information on the query target, the requestor 
SHOULD send LEASEQUERY to all DHCPv6 servers that the requestor knows 
about or is configured with. For example, the requestor MAY send 
LEASEQUERY to the All DHCP Servers multicast address. 


The requestor transmits LEASEQUERY messages according to Section 14 
of [2], using the following parameters: 


IRT LO TIMEOUT 
MRT LO MAX RT 
MRC LO MAX RC 
MRD 0 


If the message exchange fails, the requestor takes an action based on 
the requestor's local policy. Examples of actions the requestor 
might take include: 


o Select another server from a list of servers known to the 
requestor. 


o Send to multiple servers by multicasting to the All DHCP Servers 
address. 


o Terminate the request. 
3 Receipt of LEASEQUERY-REPLY 


A successful LEASEQUERY-REPLY is one without an OPTION STATUS CODE 
option (or an OPTION STATUS CODE option with a success code). There 
are three variants: 


1. If the server had bindings for the requested client, the message 
includes an OPTION CLIENT DATA option and the requestor extracts 
the client data from the LEASEQUERY-REPLY and updates its binding 
information database. If the OPTION CLIENT DATA contains no 
OPTION CLT TIME, the requestor SHOULD silently discard the 
OPTION CLIENT DATA option. 


2. If the server found bindings for the client on multiple links, 
the message includes an OPTION CLIENT LINK option. The requestor 
will need to reissue LEASEQUERY messages using each of the 
returned link-addresses to obtain the client's bindings. 
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3. If the server had no bindings for the client, neither the 
OPTION_CLIENT_DATA nor OPTION_CLIENT_LINK option will be present. 


An unsuccessful LEASEQUERY-REPLY is one that has an 

OPTION STATUS CODE with an error code. Depending on the status code, 
the requestor may try a different server (such as for NotAllowed, 
NotConfigured, and UnknownQueryType), try a different or corrected 
query (such as for UnknownQueryType and MalformedQuery), or terminate 
the query. 


4.3.4. Handling DHCPv6 Client Data from Multiple Sources 


A requestor may receive lease data on the same client from the same 
DHCPv6 server in response to different types of LEASEQUERY. If a 
LEASEQUERY is sent to multiple servers, the requestor may receive 
from several servers lease data on the same DHCPv6 client. This 
section describes how the requestor handles multiple lease data 
sources on the same DHCPv6 client from the same server or different 
servers. 


The client data from the different sources may be disjoint or 
overlapping. The disjoint and overlapping relationship can happen 
between data from the same server or different servers. 


If client data from two sources on the same client are of different 
types or values, then the data are disjoint. An example of data of 
different types is when a requestor receives an IPv6 address lease 
from one server and a prefix lease from another server, both assigned 
to the same client. An example of different values (but the same 
type) is when a requestor receives two IPv6 address leases from two 
different servers, both assigned to the same client, but the leases 
are on two different IPv6 addresses. If the requestor receives 
disjoint client data from different sources, it SHOULD merge them. 


If client data from two sources on the same client are of the same 
type and value, then the data are overlapping. An example of 
overlapping data is when a requestor receives a lease on the same 
IPv6 address from two different servers. Overlapping client data are 
also called conflicting data. 


The requestor SHOULD use the OPTION_CLT_TIME to resolve data 
conflicts originated from different servers, and SHOULD accept data 
with most recent OPTION_CLT_TIME. 
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4.4.  DHCPv6 Leasequery Server Behavior 


A DHCPv6 server sends LEASEQUERY-REPLY messages in response to valid 
LEASEQUERY messages it receives to return the statefully assigned 
addresses, delegated prefixes, and other information that match the 
query. 


4.4.1. Receipt of LEASEQUERY Messages 


Upon receipt of a valid LEASEQUERY message, the DHCPv6 server locates 
the requested client, collects data on the client, and constructs and 
returns a LEASEQUERY-REPLY. A LEASEQUERY message cannot be used to 
assign, release, or otherwise modify bindings or other configuration 
information. 


The server constructs a LEASEQUERY-REPLY message by setting the "msg- 
type" field to LEASEQUERY-REPLY, and copying the transaction ID from 
the LEASEQUERY message into the transaction-id field. 


If the query-type in the OPTION_LO QUERY option is not a known or 
supported value, the server adds an OPTION_STATUS_CODE option with 
the UnknownQueryType status code and sends the LEASEQUERY-REPLY to 
the requestor. If the query-options do not contain the required 
options for the query-type, the server adds an OPTION_STATUS_CODE 
option with the MalformedQuery status code and sends the LEASEQUERY- 
REPLY to the client. 


A server may also restrict LEASEQUERY messages, or query-types, to 
certain requestors. In this case, the server MAY discard the 
LEASEQUERY message or MAY add an OPTION_STATUS_CODE option with the 
NotAllowed status code and send the LEASEQUERY-REPLY to the 
requestor. 


If the OPTION_LO QUERY specified a non-zero link-address, the server 
MUST use the link-address to find the appropriate link for the 
client. For a QUERY BY ADDRESS, if the 0::0 link-address was 
Specified, the server uses the address from the OPTION IAADDR option 
to find the appropriate link for the client. In either of these 
cases, if the server is unable to find the link, it SHOULD return an 
OPTION STATUS CODE option with the NotConfigured status and send the 
LEASEQUERY-REPLY to the requestor. 


For a QUERY BY CLIENTID, if a 0::0 link-address was specified, the 
server MUST search all of its links for the client. If the client is 
only found on a single link, the server SHOULD return that client's 
data in an OPTION CLIENT DATA option. If the client is found on more 
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than a single link, the server MUST return the list of links in the 
OPTION_CLIENT_LINK option; the server MUST NOT return any client 
data. 


Otherwise, the server uses the data in the OPTION LQ QUERY to 
initiate the query. The result of the query will be zero or one 
client. This will result in zero or one OPTION CLIENT DATA option 
being added to the LEASEQUERY-REPLY. 


4.4.2. Constructing the Client's OPTION CLIENT DATA 


An OPTION CLIENT DATA option in a LEASEQUERY-REPLY message MUST 
minimally contain the following options: 

1. OPTION CLIENTID 

2. OPTION IAADDR and/or OPTION IAPREFIX 

3. OPTION CLT TIME 


Depending on the bindings the client has on a link, either 
OPTION IAADDR options, OPTION IAPREFIX options, or both may be 
present. 


The OPTION CLIENT DATA SHOULD include options requested in the 
OPTION ORO of the OPTION LQ QUERY option in the LEASEQUERY message 
and that are acceptable to return based on the list of "sensitive 
options", discussed below. 


DHCPv6 servers SHOULD be configurable with a list of "sensitive 
options" that must not be returned to the requestor when specified in 
the OPTION ORO of the OPTION LQ QUERY option in the LEASEQUERY 
message. Any option on this list MUST NOT be returned to a 
requestor, even if requested by that requestor. 


4.4.3. Transmission of LEASEQUERY-REPLY Messages 


The server sends the LEASEQUERY-REPLY message as described in the 
"Transmission of Reply Messages" section of [2]. 


5. Security Considerations 


Access concentrators are expected to be common leasequery requestors. 
Access concentrators that use DHCPv6 gleaning (i.e., [10]), refreshed 
with LEASEQUERY messages, will maintain accurate client/binding 
information. This ensures that the access concentrator can forward 
data traffic to the intended destination in the broadband access 
network, can perform IPv6 source address verification of datagrams 
from the access network, and can encrypt traffic that can only be 
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decrypted by the intended access modem (e.g., [12] and [13]). Thus, 
the leasequery capability allows an access concentrator to provide 
considerably enhanced security. 


The "Security Considerations" section of [2] details the general 
threats to DHCPv6, and thus to LEASEQUERY messages. The 
"Authentication of DHCP Messages" section of [2] describes securing 
communication between relay agents and servers, as well as clients 


and servers. If the requestor is an access concentrator, the IPsec- 
based [9] security as described in [2] Section 21.1 SHOULD be used. 
Other types of requestors are essentially DHCPv6 clients. Thus, 


DHCPv6 authentication, Section 21 of [2], is an appropriate mechanism 
for securing LEASEQUERY and LEASEQUERY-REPLY messages. As the number 
of leasequery requestors and servers in an administrative domain is 
relatively small, any shared key distribution issues are minimized. 


After implementing the above approaches, the DHCPv6 server should 
only be communicating with trusted LEASEQUERY requestors, and so 
security needs should be met. 


However, not all traffic originates directly from these trusted 
requestors. For example, trusted relay agents can relay LEASEQUERY 
messages from untrusted requestors or elsewhere in the network. This 
SHOULD be prevented at least at the perimeter relay agents (or on all 
relay agents unless relayed LEASEQUERY messages are required for some 
requestors). DHCPv6 servers MAY be configured to discard relayed 
LEASEQUERY messages or restrict relay chaining. 


DHCPv6 servers SHOULD also provide for the ability to restrict the 
information returned for a client in a LEASEQUERY-REPLY even to a 
trusted LEASEQUERY requestor, as described in Section 4.4.2. 


Since even trusted access concentrators may generate LEASEQUERY 
requests as a result of activity external to the access concentrator, 
access concentrators SHOULD minimize potential denial-of-service 
attacks on the DHCPv6 servers by minimizing the generation of 
LEASEQUERY messages. In particular, the access concentrator SHOULD 
employ negative caching (i.e., cache the fact that a particular 
recent query failed to return client data) and address restrictions 
where possible (i.e., don’t send a LEASEQUERY message for addresses 
outside the range of the attached broadband access networks). 
Together, these mechanisms limit the access concentrator to 
transmitting one LEASEQUERY message (excluding message retries) per 
legitimate broadband access network address after a reboot event. 


Packet-flooding denial-of-service attacks can result in the 
exhaustion of processing resources, thus preventing the server from 
serving legitimate and regular DHCPv6 clients as well as legitimate 
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DHCPv6 LEASEQUERY requestors, denying configurations to legitimate 
DHCPv6 clients as well lease information to legitimate DHCPv6 
LEASEQUERY requestors. While these attacks are unlikely when only 
communicating with trusted LEASEQUERY requestors, the possibility 
always exists that the trust is misplaced, security techniques are 
compromised, or even trusted requestors can have bugs in them. 
Therefore, techniques for defending against packet-flooding denial of 
service are always a good idea, and they include good perimeter 
security, as mentioned earlier, and rate limiting DHCPv6 traffic by 
relay agents, other network elements, or the server itself. 


One way to attack an access concentrator (as opposed to a DHCPv6 
server) as a LEASEQUERY requestor is the establishment of a malicious 
server with the intent of providing incorrect lease or route 
information to the access concentrator, thwarting source IPv6 address 
verification, and preventing correct routing. This type of attack 
can be minimized by using IPsec as described in Section 21.1 of [2]. 


6. IANA Considerations 


IANA has assigned the following new DHCPv6 Message types in the 
registry maintained in 
http://www.iana.org/assignments/dhcpv6-parameters: 


LEASEQUERY 
LEASEQUERY-REPLY 


IANA has assigned the following new DHCPv6 Option Codes in the 
registry maintained in 
http://www.iana.org/assignments/dhcpv6-parameters: 


OPTION LQ QUERY 
OPTION CLIENT DATA 
OPTION CLT TIME 
OPTION LO RELAY DATA 
OPTION LO CLIENT LINK 


IANA has assigned the following new DHCPv6 Status Codes in the 
registry maintained in 
http://www.iana.org/assignments/dhcpv6-parameters: 


UnknownQueryType 
MalformedQuery 
NotConfigured 
NotAllowed 
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IANA has created a new registry for the OPTION_LO QUERY option query- 
type codes in the registry maintained in 
http://www.iana.org/assignments/dhcpv6-parameters with the following 
initial assignments: 


QUERY_BY_ADDRESS "n 
OUERY BY CLIENTID 2 


New OPTION LQ QUERY option query-type codes are assigned through 
Standards Action, as defined in [6]. 
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